@rade Would you please take a look at this PR? I don't think it is worth spending much time with this until we see some interest from users, so I would leave it as it is...

What's all the vagrant stuff about? There's no reference to it from the Makefile or the docs.

I don't think it is worth spending much time with this until we see some interest from users, so I would leave it as it is...

Agreed that it doesn't require an in-depth review at this stage. I'd like @squaremo to take a look at this.

I am still a bit baffled by the extra layer of join/leave. Is there a sensible use for a weave node joining more than one Swarm cluster? The "basic feature" would surely be "make sure the weave network extends to the same hosts as a Swarm cluster".

"make sure the weave network extends to the same hosts as a Swarm cluster"

Actually, is this enough for that to work -- Swarm would need to be pointed at the proxy, I would think. Perhaps I have mistaken the intended use here.

I am still a bit baffled by the extra layer of join/leave

Anyway, I don't my bafflement should hold you up in exploring discovery. It's worth correcting the things Matthias mentioned, I think -- otherwise LGTM, merge if you like, @inercia, or I can.

@rade I've just realized this cannot be used for Swarm as I had in mind. Swarm nodes register in the backend their IPs in the Weave network, while Discovery needs the external, reachable IPs. So, while this can be used for getting a Weave network topology from a discovery backend, I think it could not automatically synchronize with a Swarm discovery backend...

So, to be clear, if one wants to use weave to network containers in a swarm cluster, one cannot get the weave peers to discover each other using this discovery feature?

Weave peers will discover each other as long as they a) run a Discovery and b) are pointed to the same backend (eg, etcd://someip:4001/weave). Each Discovery will register the public IP of its router, and they will all connect...

People could use Swarm in the Weave network, but they should use a different backend (eg, etcd://someip:4001/swarm) as it would contain IPs in the Weave network, and new Swarm peers registering in this backend would not be automatically joined with Discovery. A possible solution would be to calculate a Discovery backend from the Swarm backend (eg, etcd://someip:4001/swarm -> etcd://someip:4001/swarm__weave_disc) and use it for the routers' IPs, but this could create some confussion for some users (specially when they do not want to use Swarm)

So this is not as attractive as I thought, but I still think it could be useful for users that want to keep their topologies persistent (eg, so they can automatically connect after a reboot).

I have to admit that I am completely lost now. Can this weave discovery feature obviate the need to the weave connect $(docker-machine ip weave-1) in our weave with swarm guide? IMO this would be a very concrete useful thing to aim for.

I think that guide does not use Swarm in the Weave network (containers in the Swarm will be attached to Weave, but Swarm nodes do not communicate through the Weave network but directly through the external interface), and I think everything should be on top of Weave, don't you think so?

Swarm on top of weave is a different configuration. And obviously in that situation you cannot use that swarm for weave discovery.

So what's the answer to my question then? Can this discovery feature eliminate the weave connect in that guide?

In that case, Discovery could be used for eliminating that weave connect, but I think the really interesting use case is to have a clustering solution on top of our overlay network, not in parallel to it. I will finish the Vagrant for reproducing a scenario with Discovery+Swarm...